As an example, when Single Frequency Network (SFN) technology is used for MBMS delivery, the transmission area of a given service intersects with one or several Multi-cell MBMS Synchronisation Areas (MMSAs). Within each MMSA, the signal transporting the service data must be identical between all its transmitting eNodeBs. This requires time synchronisation between the transmitters and a common resource allocation scheme so that transmit opportunities overlap perfectly (within a tolerance). It is also necessary for each transmit opportunity to encode the same block of data, and so achieve content synchronisation. For this purpose, all the eNodeBs in an MMSA receive the service data packets from a single source, the Multi-cell Coordination Entity (MCE), which delivers the packets using a SYNC protocol which may be time stamp based or byte-offset based or otherwise.
Byte level sequence number based content synchronisation is a relative synchronisation method. That is packets are not assigned any specific transmission time via a timestamp, but the method still ensures that any given packet is transmitted simultaneously by all the eNodeBs of an MMSA. The packets are issued by the MCE with a byte offset which effectively locates them precisely within the stream of bytes formed by the sequence of blocks allocated to the MBMS service, a starting time having been defined. The actual placement implied by a byte offset depends on the overhead spend packing earlier packets, but since all eNodeBs pack packets according to the same rules, content synchronisation is maintained.
Normally with this scheme, the byte offset associated with a packet is equal to that associated with the previous packet plus the size of the previous packet. It should be noted that, as with any scheme, the allocated capacity must be slightly larger than the actual volume of data. This means that idle gaps must be managed from time to time within the packet flow, not to be confused with packets which may be missed by any eNodeB.
The MCE might generate idle gaps in the stream of packets if it encounters itself a gap the upstream flow. However, idle gaps are supposed to adjust the data rates of the source to the actual rate of the air-interface. If the MCE is completely unaware of the overhead consumed by eNodeBs (and it is not constant), it cannot ensure that queuing in the eNodeBs will remain stable. In fact resources would be allocated to avoid average queue growth, which means that the quest would tend to run out of data. The synchronisation method would have to handle this situation or avoid it in the first place by managing idle synchronised gaps in good time.
When an eNodeB detects that it has missed one or more packets, although it cannot transmit any of the blocks affected by the loss (as blocks cannot be partially transmitted), it must determine how many blocks to skip and on which byte to resume transmission in order to stay synchronized with the eNodeBs which did not suffer any loss.
While it might seem that the eNodeB knows the size of the gap from the difference in byte offsets associated with the received packets (before and after the loss), it should be appreciated that the size does not include the overhead added by the packing process. The eNodeB therefore needs to compute the overhead that the other eNodeBs will have spent. That is, it must emulate the packing of the missing data. If only a single packet was lost, then there is only one way it could have been packed. But, at this stage, the eNodeB cannot know that and should not assume it. If several packets were missing, only knowing to sum of their sizes is not sufficient as, in general, the overhead varies according to how the packets fit in the blocks.
From 3 gPP proposal Ericsson, Tdoc R2-070573, there is a known suggestion in which the computation of the overhead is trivial: each block devotes a fixed amount of space to the header; the overhead is therefore constant and so is the amount of user data transported.
However, this known proposal exhibits two limitations and disadvantages.
First there is unused header space, except in the extreme case of a maximum of concatenated packets, which is a rare case. Secondly, in reducing the header, in order to reduce wastage, there is an increased risk of coming across a sequence of packets which uses up the header space, causing waste with unusable space in the data part of the block, then either data loss (by dropping the data that might have fitted in the unused space or delay (by packing this data in the following block).